<div class="container" id="container">
  <div class="page article js_show">
    <div class="page__hd">
      <h1 class="page__title">重构的准备</h1>
      <p class="page__desc">我们是否走在正确的道路上</p>
    </div>
    <div class="page__bd">
      <article class="weui-article">
        <h1></h1>
        <section>
          <h2 class="title"></h2>
          <section>
            <h3>了解过去</h3>
            <p>
              <p>
                系统的价值可以分为两部分，一块是业务，一块是技术。
                业务是核心，技术用来实现业务逻辑。
                我们要重构的大多在技术层面，但是业务层面的改动往往也是导致系统重构的原因之一。
                我们在重构系统过程中(或之前),  我们要从业务和技术两个方面去了解原来的系统。
                业务方面，我们要了解: 系统的目标和受众，系统的演变方向；
                技术方面，需要了解原来框架技术组成是什么样的，目前的技术框架存在哪些局限性，又
                有哪些优势，可以从哪些方面进行改进。
              </p>
              <p>
                大多时候，业务和技术是相辅相成的。
                技术的实现过程中往往可以发现业务在设计上的不足和一致性的缺乏；业务的不断增强也可
                发现技术架构在可扩展性方面的缺陷。
                业务和技术本是一个整体构成一个系统，一个程序员不了解业务是不行的，如果能在业务方面
                提出一些假设性的意见，不管对系统的演变还是对自身的发展都是大有裨益的。
              </p>
            </p>
          </section>
        </section>

        <section>
          <h2 class="title">重构需要遵循的准则</h2>
          <section>
            <h3>相爱相杀的故事</h3>
            <p>
              对于业务系统的设计和改造，普通程序员往往缺乏发言权。
              然而，很多复杂到难以维护的设计往往是因为过分的完全基于主观的业务功能设计。
              在很多时候，系统的使用者往往只有传统行业的知识，缺乏对于网页或则软件的基本知识，他们要么对
              系统有着不切实际的超强期待，亦或者根本提不出任何改进意见。业务确实是非常重要的，然而技术开发者
              往往也是基于自己的最佳实践经验的总结，业务人员应该也是欢迎与技术人员之间进行的交流。
            </p><p>
              在传统的以业务为导向的公司，通常存在这样世世代代的互怨互恨的故事。
              故事的开始，业务人员和程序员都开心得到一家公司为老板服务。程序员可以写自己喜欢的代码并且学习到一些业务知识，
              业务人员线下的业务可以在程序员的帮助下自动化，自己的业绩可以得到提升。
              然而，当一个系统正式进入开发阶段以后，
              因为业务的强势，程序员在系统中加入了很多
              天才般的业务实现代码，以至于系统不具有可扩展性或则其性能极具下降。当业务规模不断发展的时候，程序员发现新的功能无法添加了，
              业务发现系统性能越来越差，添加新功能的周期越来越长。业务员心想，这一帮闲人，老子赚钱养活你们，你们就整这一个破系统，严重
              阻碍了业务的发展，迟早得把你们这帮无用得换掉；程序员心想，这个公司对程序员根本不尊重，一帮不懂技术的人在乱指挥，再有能耐
              也搞不定这帮人的需求，咱惹不起还躲不起吗？一段相爱相杀的故事一遍遍在各个公司上演着。
            </p>
          </section>

          <section>
            <h3>技术重构的准则</h3>
            <p>
              <h4>我们需要标准</h4>
              <p>
                技术结构应尽可能的清晰：模块化，单一职责，可测试性。
                <p>
                  “模块化”希望系统只加载自己需要的资源，对于网页来说，每个页面的交互都需要加载很多资源，因为所有资源都必须
                  先加载到本地才能执行，所以会让系统的加载非常缓慢。此外，代码模块化，也有利于对代码的复用。
                </p>
                <p>
                  “单一职责”原则要求特定的代码模块应该只执行目标明确的操作，这对与问题排查定位具有很好的辅助作用。试想，如果JS、HTML，CSS
                  如果都在修改页面的显示，如果出现页面显示问题该如何排查呢？
                </p>
                <p>
                  “可测试性”是系统能够不断升级演化的重要前提，也是重构过程中必不可缺的步骤，即使我们进行很微小的改动也可能引入新的问题，在
                  复杂系统中，如果没有自动化测试工具进行辅助，我们几乎很难建立起对该系统的稳定性的信心。
                </p>
              </p>
            </p>
          </section>
        </section>

        <section>
          <h3>重构的步骤建议</h3>
          <p>
            <h4></h4>
            <p>
              <li>1. 了解系统需要重构部分的业务逻辑和技术实现</li>
              <li>2. 分析目前系统业务逻辑和技术实现存在的问题</li>
              <li>3. 设置重构目标，可以是用户体验也可以是性能的提升，甚至是代码的可读性</li>
              <li>4. 对需要重构的部分添加自动化测试案例，确保自动化测试覆盖需要重构的关联部分</li>
              <li>5. 对代码进行重构</li>
              <li>6. 测试重构后的系统</li>
              <li>7. 回到1</li>
            </p>
          </p>
        </section>
      </article>
    </div>
    <div class="page__ft" style='display:none'>
      <a href="javascript:home()"><img src="./images/icon_footer_link.png"></a>
    </div>
  </div></div>
